The infrastructure of the Session Initiation Protocol (SIP) is defined in IETF RFC 3261 (Rosenberg et al., June 2002). In general, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
In “SIP-Specific Event Notification”, A. Roach, RFC 3265, July 2002 (referred to hereafter simply as RFC 3265), there is described a SIP event framework to enable event-based information provisioning to any node in the Internet. This procedure is expected to become a key element within the SIP infrastructure. Examples of this kind of information are presence, location information, content/service availability, or access-controlled SIP events.
As is discussed in RFC 3265, the general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. A typical flow of messages would be:
SubscriberNotifier|-----SUBSCRIBE---->|Request state subscription|<-------200--------------|Acknowledge subscription|<------NOTIFY---------|Return current state information|--------200------------->|Acknowledge|<------NOTIFY--------|Return current state information|--------200------------->|Acknowledge
Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages.
Several useful definitions include the following:
Event Package: An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by RFC 3265 that are required to convey such state information.
Event Template-Package: An event template-package is a special kind of event package which defines a set of states which may be applied to all possible event packages, including itself.
Notification: Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.
Notifier: A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.
State Agent: A state agent is a notifier which publishes state information on behalf of a resource; in order to do so, it may need to gather such state information from multiple sources. State agents always have complete state information for the resource for which they are creating notifications.
Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.
Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.
Subscription Migration: Subscription migration is the act of moving a subscription from one notifier to another notifier.
The SUBSCRIBE method is used to request current state and state updates from a remote node.
J. Rosenberg has defined in “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)”, draft-ietf-simple-winfo-package-05.txt, Jan. 31, 2003, a watcher information template-package for the SIP event framework. Watcher information in this context refers to a set of users that are subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore can learn of changes to this information. This particular event package is referred to as a template-package, as it can be applied to any event package, including itself.
As was noted above, the SIP event framework defined in RFC 3265 is intended to enable event-based information provisioning to any node in the Internet. SIP events are used to provide a notification scheme that allows for conveying state changes of a particular resource, or changes of aggregated states relating to a pool of resources, to subscribers for the state information. Examples for this kind of information are presence (see J. Rosenberg, “A Presence Event Package for the Session Initiation Protocol (SIP)”, Internet Draft, Internet Engineering Task Force, (work in progress), January 2003), location information or content/service availability (see, for example, US 2004/0003058 A1, D. Trossen, “Integration of Service Registration and Discovery in Networks”, Ser. No. 10/179,244, filed Jun. 26, 2002). In these cases the resource is the presentity, the location information or the content/service information, and changes to these resources are conveyed to subscribers as event notifications.
In scenarios for using SIP events, it is usually assumed that the SIP event server, i.e., the server hosting the event state, is aware of the resource information in order to determine the state information. For example, a presence server is assumed to be aware of the presence information of the presentities in order to determine the current presence status. If such presentity information is unknown, however, the presence status is assumed as being “not present”(see, again, J. Rosenberg, “A Presence Event Package for the Session Initiation Protocol (SIP)”, Internet Draft, Internet Engineering Task Force, (work in progress), January 2003)).
However, there maybe cases in which the resource information for determining the event state is only sporadically available at the SIP event server, leading to a temporary unavailability of the event state as such, and thus defining the event state as “undetermined” during these periods. Consider in this regard the following exemplary use cases.
As a first use case (Group Presence) assume a subscription to a group presence (for example, a group of mothers) expressed as a group URI such as “pres:soccermom1234@service_provider.com”. The group presence is determined at the service_provider presence server through individually subscribing to the presence of each group member. The notifications to the subscriber would indicate the presence of the entire group (i.e., the group is present if all members are present), which could be used to initiate certain group services (such as chat). However, it may occur that during the subscription to the group, individual presence information becomes unavailable, such as due to a failure of individual presence servers. In this case no notifications would be sent to the subscriber, since the “present” status cannot be determined during this “blackout” period due to the partially missing, individual presence information.
As a second use case (Context Information) one may generalize the Group Presence use case. For this purpose consider the provisioning of any context information (such as presence, location, but also sensor-based information) through SIP events as, for example, is described in commonly assigned U.S. patent application Ser. No. 10/862,868, filed Jun. 7, 2004, “Method, System and Computer Program to Enable Semantic Mediation for Sip Events Through Support of Dynamically Binding to and Changing of Application Semantics of Sip Events”, by Dirk Trossen and Dana Pavel. At the time of subscription, the particular SIP event server accepts the subscription since the resources for determining the desired event state are generally available at the server. However, throughout the subscription, some of the resource information (for example, certain remote sensors) may become temporarily unavailable so that the subscribed event state cannot be determined during this time. As a consequence, the subscriber would not receive any notification throughout the temporary “blackout”. However, it is possible that the subscribed state indeed did change throughout this “blackout”, it could simply not be determined by the SIP event server due to the unavailability of the required input information.
As an example consider a subscription to context information that requires location information as one input parameter. However, the location information may become temporarily unavailable during the subscription (e.g., because of shadowing effects in the location determination) so that the entire context information for the subscription cannot be determined temporarily.
In both of the foregoing use cases it would be desirable if there existed a technique to convey the temporary unavailability of resource information (and therefore the inability to determine the event state) to the subscriber. The reason for this is that there is a semantic distinction between not receiving notifications because the subscribed event state has not changed (e.g., in the above context provisioning use case, the desired context has not been triggered), or because the subscribed event state could not be determined at least temporarily. In other words, as currently specified in a SIP event environment the subscriber cannot easily differentiate between a “no change in event state” condition or a “temporary unavailability of input information” condition.
Within the current SIP event framework, the described use cases related to the problem of sporadic availability of required input information are solved by either terminating the particular subscription from the event server's side (therefore indicating the unavailability of the resource input) or by sending event-specific notifications to the subscriber that would indicate such unavailability.
However, the former conventional approach leads to problems when the unavailability of resource input occurs frequently throughout the lifetime of the application that subscribes to the resource. As a consequence, the subscription terminations result in frequent re-subscription and terminations each time the resource input becomes temporarily unavailable. Such frequent subscriptions/terminations place an undesirable burden on both the subscriber and the SIP event server.
The latter conventional approach, i.e., event-specific notifications, is by definition event-specific and therefore requires proper integration into the semantics of any event that is subject to temporary unavailability of input information. However, even in this case the conveyance of the unavailability-related information in principle violates the paradigm of the subscription in the sense that instead of conveying event state information, the notifications are instead used for making availability notifications (which carry a different semantic). It is important to note in this regard that the subscriber subscribes to the event state as such, and not to the availability of the input information (in particular, because the subscriber may not be aware of what input information is used by the event server for making the event state determination). In other words, even though the event state may not have changed, the notifications are used to convey information, which is not related to the event state as such, back to the subscriber. This can be readily seen as an improper usage of the original (event state) subscription.
A need thus exists to provide a mechanism for a SIP event server to convey an occurrence of a temporary unavailability of input information, and to do so while maintaining the original subscription dialog through usage of an event template package that is associated with the particular event package of the original subscription. It would also be desirable to perform this function without the need of frequently terminating and re-establishing subscriptions for events that require input from sporadically available sources. Prior to this invention, such a mechanism did not exist.